-
Notifications
You must be signed in to change notification settings - Fork 9.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
providers/aws: Validate IOPs for EBS Volumes #4146
Conversation
Just to clarify, does this still allow passing in a false value to iops? Currently we have a module that accepts two arguments: storage_type and iops. We use this with both gp2 and io1. For example:
Basically we need our module to accept both gp2 and io1 storage types. My intuition is that d.GetOk("iops") will return the "false" value and fail validation. |
Sorry, no :(
|
The underlying problem that I'm dealing with is that there's I haven't found away in Terraform to conditionally set an argument in a module. That is, only set the "iops" if it's passed in to the module. You can't allow both (storage_type = gp2) and (storage_type = io1, iops = 200). That's more an issue with Terraform than it is with this PR, which does the sensible thing. Unfortunately it probably means I'll have to have two modules, one for gp2 and one for io1, unless I can find a better workaround. |
@catsby I think the zero value here can just skip the validation so that this would work:
I'd actually expect us to have some sort of gp2 exercising acctest that would be failing now w/ an |
Agreed. I'll remove the strict validation. @billputer would |
@catsby Yup, that should do the trick. |
@billputer had to tweak it some, but I think this should work for you. Any chance you can try it out? Otherwise I'll just nag @phinze 😄 |
This LGTM (assuming we don't want to wait to fix this with whatever @phinze is cooking up for resource-level validation!) |
don't know, @phinze: should I delay? |
Let's merge this as-is and we can follow up once ResourceValidateFunc finally lands. The conditional read stuff is still going to be valid no matter what we do for validation. |
providers/aws: Validate IOPs for EBS Volumes
- Already ignoring IOPS on ebs attached non-io1 devices; extended to root_block_device - Added warning captured from hashicorp#4146 / [../blob/master/builtin/providers/aws/resource_aws_ebs_volume.go#L104](resource_aws_ebs_volume.go#L104) - Added test when setting IOPS to 330 (11GiB * 30 = 330) on GP2 root device results in AWS reported 100 IOPS (successfully ignored input)
- Already ignoring IOPS on ebs attached non-io1 devices; extended to root_block_device - Added warning captured from #4146 / [../blob/master/builtin/providers/aws/resource_aws_ebs_volume.go#L104](resource_aws_ebs_volume.go#L104) - Added test when setting IOPS to 330 (11GiB * 30 = 330) on GP2 root device results in AWS reported 100 IOPS (successfully ignored input)
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
IOPs must be an integer.
The range varies by instance size (docs here)pl, so we simply validate that it's an integer.
IOPs is also not valid for any type that is not
io1
. Unfortunately I don't believe we can check for that in theplan
phase, but we validate that in theapply
phase hereAlso, a minor fix to the docs:
us-west-1a
does not exist